WIP nabu rodriguezst configs - #2

RISC-V computes vmemmap_start_pfn by rounding phys_ram_base down to
VMEMMAP_ADDR_ALIGN.  That alignment must therefore be expressed in the
physical-address domain.

Commit 476849b ("riscv/mm: align vmemmap to maximal folio size")
attempted to account for the maximal folio alignment by feeding
MAX_FOLIO_VMEMMAP_ALIGN directly into VMEMMAP_ADDR_ALIGN.  However,
MAX_FOLIO_VMEMMAP_ALIGN is measured in bytes of struct page storage,
whereas VMEMMAP_ADDR_ALIGN is used to align a physical address.

The mask-based compound_info encoding requires pfn_to_page(0) to be
naturally aligned to MAX_FOLIO_VMEMMAP_ALIGN.  Commit 9f94db4
("mm/sparse: check memmap alignment for compound_info_has_mask()") added a
check for that requirement and exposed the unit mismatch on systems such
as QEMU virt, where the DRAM base is not aligned to MAX_FOLIO_NR_PAGES *
PAGE_SIZE.

Here is the log:
[    0.000000][    C0] ------------[ cut here ]------------
[    0.000000][    C0] WARNING: mm/sparse.c:365 at sparse_init+0x58a/0x6fe, CPU#0: swapper/0
[    0.000000][    C0] Modules linked in:
[    0.000000][    C0] CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 7.2.0-rc3-g1d8304bdd65f #2 PREEMPT 
[    0.000000][    C0] Hardware name: riscv-virtio,qemu (DT)
[    0.000000][    C0] epc : sparse_init+0x58a/0x6fe
[    0.000000][    C0]  ra : sparse_init+0x58a/0x6fe
[    0.000000][    C0] epc : ffffffff86851c88 ra : ffffffff86851c88 sp : ffffffff88807a30
[    0.000000][    C0]  gp : ffffffff8a3bf240 tp : ffffffff88842080 t0 : ff600000ffab6000
[    0.000000][    C0]  t1 : 000000017fab6000 t2 : 65203a6573726363 s0 : ffffffff88807bc0
[    0.000000][    C0]  s1 : 000000000e000000 a0 : 0000000000000007 a1 : 0000000000000000
[    0.000000][    C0]  a2 : 0000000000000002 a3 : ffffffff86851c88 a4 : 0000000000000000
[    0.000000][    C0]  a5 : ffffffff88843080 a6 : 0000000000000003 a7 : 0000000000000000
[    0.000000][    C0]  s2 : ff60000000000000 s3 : 0040000000000000 s4 : 0004000000000000
[    0.000000][    C0]  s5 : ffffffff8a4d92e0 s6 : ff600000ffab55e0 s7 : ffffffff88384d00
[    0.000000][    C0]  s8 : 0000000000000003 s9 : ffffffff88384cc1 s10: ffffffff88384cc0
[    0.000000][    C0]  s11: ffffffff8a4daae0 t3 : ffffffff915e8b20 t4 : ffffffff915e8b20
[    0.000000][    C0]  t5 : ffffffff915e8b20 t6 : ffffffff915e8bc8 ssp : 0000000000000000
[    0.000000][    C0] status: 0000000200000100 badaddr: ffffffff86851c88 cause: 0000000000000003
[    0.000000][    C0] [<ffffffff86851c88>] sparse_init+0x58a/0x6fe
[    0.000000][    C0] [<ffffffff8683d396>] mm_core_init_early+0x116/0x1e30
[    0.000000][    C0] [<ffffffff86801edc>] start_kernel+0xd2/0x848

Convert MAX_FOLIO_VMEMMAP_ALIGN to the equivalent physical alignment
before using it in VMEMMAP_ADDR_ALIGN.  This keeps the existing
round_down() logic while making the resulting vmemmap base satisfy the
mask-alignment requirement.

Link: https://lore.kernel.org/20260716115326.3466926-1-xujiakai2025@iscas.ac.cn
Fixes: 476849b ("riscv/mm: align vmemmap to maximal folio size")
Signed-off-by: Jiakai Xu <xujiakai2025@iscas.ac.cn>
Reviewed-by: Kiryl Shutsemau (Meta) <kas@kernel.org>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Alexandre Ghiti <alex@ghiti.fr>
Cc: David Hildenbrand <david@kernel.org>
Cc: Guo Ren <guoren@kernel.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Nam Cao <namcao@linutronix.de>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Vishal Moola (Oracle) <vishal.moola@gmail.com>
Assisted-by: YuanSheng:DeepSeek-V4-Flash
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

[BUG]
There is a bug report that on 32bit systems (i686), btrfs crashes when
trying to do zstd compression:

  BUG: unable to handle page fault for address: fffbc000
  #PF: supervisor read access in kernel mode
  #PF: error_code(0x0000) - not-present page
  CPU: 0 UID: 0 PID: 61 Comm: kworker/u8:5 Tainted: G                 N  7.2.0-rc3-P3 #2 PREEMPTLAZY
  Hardware name: LENOVO 2007F2G/2007F2G, BIOS 79ETE7WW (2.27 ) 03/21/2011
  Workqueue: btrfs-delalloc btrfs_work_helper
  EIP: ZSTD_compressStream2+0x221/0x5fc
  Call Trace:
   ZSTD_compressStream+0xd/0x48
   zstd_compress_stream+0x8/0x10
   zstd_compress_bio+0x20a/0x564
   btrfs_compress_bio+0x94/0xc0
   compress_file_range+0x20a/0x380
   btrfs_work_helper+0xc1/0x1b4
   process_scheduled_works+0x15f/0x204
   worker_thread+0x10c/0x178
   kthread+0xe1/0xe8
   ret_from_fork+0x1d/0x14c
   ret_from_fork_asm+0x12/0x18
   entry_INT80_32+0xf0/0xf0
  CR2: 00000000fffbc000
  ---[ end trace 0000000000000000 ]---

[CAUSE]
Inside zstd_compress_bio(), we assume the whole page cache folio can be
mapped in one go.

However that assumption is not true on systems with CONFIG_HIGHMEM, the
pages of the large folio can be in HIGHMEM, which needs to be mapped
before access.

Meanwhile zstd_compress_bio() only map the page of a large folio where
the start filepos is, the remaining pages are not mapped, and accessing
the remaining pages will trigger the above crash.

[FIX]
Do not enable large folios when the kernel has CONFIG_HIGHMEM enabled.

This is the same handling for bs > ps support.

Link: kdave/btrfs-progs#1146
Reported-by: Erhard Furtner <erhard_f@mailbox.org>
Fixes: 9bce95e ("btrfs: move large data folios out of experimental features")
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>

rt6_nh_dump_exceptions() uses hlist_for_each_entry() to iterate over
RCU-protected exception lists. The caller holds rcu_read_lock(), but does
not hold rt6_exception_lock, so rt6_insert_exception() can concurrently
add an entry with hlist_add_head_rcu().

KCSAN reports this race (irrelevant details omitted):

  ==================================================================
  BUG: KCSAN: data-race in rt6_insert_exception / rt6_nh_dump_exceptions

  write (marked) to 0xffff8a7c44c59620 of 8 bytes by interrupt on cpu 5:
    rt6_insert_exception+0x3bb/0x760
    __ip6_rt_update_pmtu+0x4fe/0x750
    ip6_sk_update_pmtu+0x19a/0x3b0
    udpv6_err+0x3ff/0x800
    icmpv6_notify+0x1e1/0x440
    icmpv6_rcv+0x8c0/0xab0
    ip6_protocol_deliver_rcu+0x616/0x840
    ip6_input_finish+0xb9/0x160
    ...
    entry_SYSCALL_64_after_hwframe+0x77/0x7f

  read to 0xffff8a7c44c59620 of 8 bytes by task 549 on cpu 14:
    rt6_nh_dump_exceptions+0xb3/0x260
    rt6_dump_route+0x53e/0x5f0
    fib6_dump_node+0x6d/0xf0
    fib6_walk_continue+0x290/0x2d0
    fib6_dump_table+0x28d/0x360
    inet6_dump_fib+0x37d/0x620
    rtnl_dumpit+0x7b/0xd0
    netlink_dump+0x3ae/0x7e0
    ...
    entry_SYSCALL_64_after_hwframe+0x77/0x7f

  4 locks held by dumper/549:
    ...
    #1: (rcu_read_lock){....}-{1:3}, at: inet6_dump_fib+0x88/0x620
    #2: (&tb->tb6_lock){+.-.}-{3:3}, at: fib6_dump_table+0x1e9/0x360
    #3: (rcu_read_lock){....}-{1:3}, at: rt6_dump_route+0x483/0x5f0

  value changed: 0xffff8a7c44e05700 -> 0xffff8a7c45d60100

  Reported by Kernel Concurrency Sanitizer on:
  CPU: 14 UID: 0 PID: 549 Comm: dumper Not tainted
  7.2.0-rc7-virtme #38 PREEMPT(lazy)
  ...

Use hlist_for_each_entry_rcu() to safely iterate over the exception list.

Fixes: 1e47b48 ("ipv6: Dump route exceptions if requested")
Cc: stable@vger.kernel.org
Signed-off-by: Yuyang Huang <sigefriedhyy@gmail.com>
Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260815084651.69477-1-sigefriedhyy@gmail.com
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

…ommands'

Tariq Toukan says:

====================
net/mlx5: Preserve speed and state across vport modify commands

The firmware vport modify command bundles both admin state and max tx
speed in a single operation, which requires each side to preserve the
other field when it only intends to change one.

When modifying max tx speed, the driver already queries the current
admin state and passes it back to avoid overwriting it. However, this
query and the subsequent modify were not atomic, a state change
between the two could cause the modify to overwrite the new state with
a stale value. The fix holds esw->state_lock across the query-modify
sequence.

When support for setting max tx speed via the vport modify command was
introduced, the existing admin state modify path was not updated to
preserve the current speed. As a result, the firmware interprets the
zero speed field as an intentional reset. The fix adds a speed query
before the state modify and passes the result back in the command.

To support that, mlx5_query_vport_max_tx_speed() had to be fixed first:
it was returning zero whenever the vport was DOWN, which was correct
for the query_port_speed verb but would defeat the purpose of querying
before a state modify. The DOWN-to-zero logic is moved to the
verb-layer caller so the function returns the raw firmware value.

Patch #1  holds esw->state_lock across the state query and modify in
          the speed modify path
Patch #2  moves the vport DOWN zero mapping to the verb-layer caller
          so the query returns the raw firmware value
Patch #3  queries current max tx speed before modifying vport state to
          preserve it
====================

Link: https://patch.msgid.link/20260816065015.3280733-1-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

The `rustc-dev` components for Rust 1.82.0 through 1.87.0 include a
precompiled `zerocopy_derive` procedural macro in the sysroot. This
range includes Rust 1.85.0, our minimum supported version.

This makes `rusttest` fail because the compiler finds both the sysroot
copy and the copy built in `rust/test`:

    error[E0464]: multiple candidates for `dylib` dependency `zerocopy_derive` found
      --> rust/kernel/prelude.rs:70:9
       |
    70 | pub use zerocopy_derive::{
       |         ^^^^^^^^^^^^^^^
       |
       = note: candidate #1: .../lib/rustlib/x86_64-unknown-linux-gnu/lib/libzerocopy_derive-54d2b38896fa6bc5.so
       = note: candidate #2: .../rust/test/libzerocopy_derive.so

Commit fe39a23 ("rust: kbuild: disambiguate `zerocopy` for
`rusttest`") fixed the equivalent ambiguity for `zerocopy`.

Thus point to the dependency explicitly in this case too.

Cc: Antoni Boucher <bouanto@zoho.com>
Cc: stable@vger.kernel.org
Fixes: 5060549 ("rust: zerocopy-derive: enable support in kbuild")
Link: https://patch.msgid.link/20260823193529.156066-1-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

A virtio_net_hdr (tun/tap, or AF_PACKET with PACKET_VNET_HDR) can mark
an IPv4 or IPv6 fragment as GSO; nothing relates gso_type to frag_off.
inet_frag_reasm_prepare()/inet_frag_reasm_finish() keep the first
fragment's skb as the head of the reassembled datagram, including its
shinfo->gso_size/gso_type/gso_segs, and chain the remaining fragments
on frag_list with whatever linear/paged layout they arrived with.

After ip_defrag() (ip_local_deliver(), nf_defrag_ipv4, ...) the
reassembled skb therefore still claims to be GSO (SKB_GSO_DODGY), and
the next software segmentation point - udp_rcv_segment() on local
delivery, validate_xmit_skb(), or the ip_finish_output_gso() slow
path - hands it to skb_segment(). skb_segment()'s frag_list walk
assumes GRO-shaped input and hits one of its BUG_ON()s. Two writes to
a tap by an unprivileged user in its own userns are enough:

  kernel BUG at net/core/skbuff.c:4899!
  Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
  CPU: 0 UID: 1000 PID: 82 Comm: poc Not tainted 7.2.0-pentest+ #2
  RIP: 0010:skb_segment+0x20ca/0x48b0
  Call Trace:
   <TASK>
   __udp_gso_segment+0x29a/0x27d0
   udp4_ufo_fragment+0x458/0x6c0
   inet_gso_segment+0x429/0x1340
   skb_mac_gso_segment+0x233/0x4f0
   __skb_gso_segment+0x308/0x660
   udp_queue_rcv_skb+0x440/0xad0
   udp_unicast_rcv_skb+0xc7/0x2c0
   udp_rcv+0x16ce/0x2260
   ip_protocol_deliver_rcu+0x197/0x2d0
   ip_local_deliver+0x430/0x690
   ip_rcv+0x16f/0x1f0
   __netif_receive_skb_one_core+0x15e/0x1c0
   __netif_receive_skb+0x1e/0x110
   netif_receive_skb+0xf6/0x5c0
   tun_rx_batched.isra.0+0x3ab/0x790
   tun_get_user+0x17c3/0x3550
   tun_chr_write_iter+0xba/0x1b0
   vfs_write+0x646/0x1130
   </TASK>
  Kernel panic - not syncing: Fatal exception in interrupt

This runs with BH disabled, so it is a panic rather than an oops. The
same is reachable with CAP_NET_RAW in a netns where a defrag point
precedes a GSO point, and from a guest whose VMM forwards
virtio_net_hdr to a tap. The SKB_GSO_DODGY frag_list checks added by
commit 3dcbdb1 ("net: gso: Fix skb_segment splat when splitting
gso_size mangled skb having linear-headed frag_list") and by
commit 9e4b7a9 ("net: gso: fix panic on frag_list with mixed head
alloc types") do not cover it: page-backed heads skip them, and kmalloc
heads skip them when gso_size == skb_headlen(head), which the sender
controls.

An skb entering a frag queue is an IP fragment by definition and
cannot legitimately carry GSO state: GRO does not merge fragments and
the stack segments before it fragments, so only untrusted sources are
affected. This has been reachable since
commit f43798c ("tun: Allow GSO using virtio_net_hdr"), the first
path that let userspace attach GSO metadata to an IP fragment. Reset
the GSO fields of every fragment as it is queued, in
inet_frag_queue_insert(), which IPv4, IPv6, nf_conntrack_reasm and
6lowpan reassembly share; then neither the head nor the frag_list
members of the reassembled skb carry them (the members matter too:
the ip_do_fragment()/ip6_fragment() fast paths send them out as they
are). The head may remain CHECKSUM_PARTIAL; that is already accepted
on receive and resolved by skb_checksum_help() in
ip_do_fragment()/ip6_fragment() on forward.

Tested on top of net.git (dc4b95b), x86_64: the tap reproducer
above, two further IPv4 frag_list geometries that reach
BUG_ON(i >= nfrags) and BUG_ON(!list_skb->head_frag), and an IPv6
fragment-header variant (udp6_ufo_fragment()) each panic the unpatched
kernel; with this patch all four datagrams are delivered intact and
nothing is logged.

Fixes: f43798c ("tun: Allow GSO using virtio_net_hdr")
Cc: stable@kernel.org
Suggested-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Xinyang Ge <xinyang@anthropic.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/937926e509f2acd8e0e66520dc2b30fd6b4d1687.1787839506.git.pabeni@redhat.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>